Software systems comprising various components frequently utilize log databases to track system and component operation for diagnostic purposes. An “event log” may be used to chronologically stores events that are generated by different software components in the system. Software components may generate events as responses to certain combinations of their internal state and stimuli from, for example, other software modules, the hardware, or the user.
The logged events typically fall into one of three categories: “Error Events” are generated when errors are found or exceptional or unexpected things occur; “Success Events” are generated as information indicating that aspects of the system are running properly; and “Information Events” are generated as information indicating that certain informational things occur.
Event can further more be assigned a severity level. Different Error Events may, for example, have different severity levels. The Success Events and the Information Events are usually indicated as having a lower severity level than the Error Events.
The event log can be broken down as having different access levels as well. For example, only system administrators may have access to certain secure logs (“Internal Event Log”) or sections of the log or events (e.g., security violations, etc.), whereas software component users may have access to various logs (“User Event Log”) or log sections pertaining to operation of the respective software component.
For the user, the User Event Log shows a filtered version of the Internal Event Log. The purpose of filtering the Internal Event Log is to avoid showing irrelevant and redundant information to the user. The User Event Log only shows events with a particular criticality level (this level being a configurable level). Events are displayed in the User Event Log until the user acknowledges them. The user interface may show a special icon as long as the User Event Log contains at least one unacknowledged event. The User Event Log shows the filtered events in reverse chronological order, so that the most recent one is displayed at the top in a list. Using a separate user interface, the user can view the complete User Event Log, that is, the user log that also includes the acknowledged events. Events in the User Event Log can be automatically acknowledged when Success Events are received.
Both the Internal Event Log (for systems personnel) and the User Event Log (for users) are provided to help diagnose problems in the system.
The problem with such log files, however, is that the User Event Log shows too many events or not the most relevant ones. Each significant problem that interests the user may generate more than one event. Because the events are shown chronologically, the most important ones are not necessarily at the top.
Furthermore, on such systems, the explanatory text shown for each event may describe the cause for the problem, but the event cause text is static and is not influenced by other events. Some events may have different causes. Because the explanation is static, it then must either describe all possibilities, or else omit some or all causes. This can be confusing, especially when multiple events are present in the User Event Log because of conflicting, redundant, or insufficient information.
The explaining text shown for each event may describe an appropriate repair action to solve the problem. The problem is that the event action text is static and not influenced by other events. For some events, it may not be possible to specify a single repair action because the appropriate repair actions depends on additional information. Since the explanation is static, it then must describe all possibilities, or omit some or all repair actions. This too can be confusing, especially when multiple events are present in the User Event Log because of conflicting, redundant, or insufficient instructions.
Software that automatically performs repair actions is lacking. Some problems can be repaired with software programs. Such repair actions could be performed automatically if a diagnosis can be automatically found, or perhaps allowed to run when acknowledged by the user.
Software is needed that tries to diagnose by analysing multiple events. Some problems can only be conclusively diagnosed by considering more than one event or additional information.
The Internal Event Log does not always contain enough information for a conclusive diagnosis. It would be useful if also other information sources could be used for diagnostic purposes. Such information sources could be log files, data or program module state information.
In some cases additional information necessary for a conclusive diagnosis could be collected automatically by calling test functions. This possibility does not presently exist. The technical problem is to find out when such test functions should be called. For performance reasons, it is not reasonable to execute them e.g., for each received event.
Necessary information for a conclusive diagnosis is not always possible to collect automatically without intervention from the user. Some things can only, or easiest, be checked by the user. The diagnostic capability of the system could be improved if the diagnosis software would prompt for or accept manual test results.
Some of the Wizards in modern Microsoft products are an example of efficient diagnostic tools. The user is guided through a series of dialogs that serves to collect information and home in on the problem cause.
It is known to have event logs where events are classified by severity and the most severe ones are shown at the top of a list. Usually they can be acknowledged and are then moved to a history list for later analysis, when required.